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Abstract 

A bidirectional transformation is a pair of mappings between source 
and view data objects, one in each direction. When the view is 
modified, the source is updated accordingly with respect to some 
laws. One way to reduce the development and maintenance effort 
of bidirectional transformations is to have specialized languages 
in which the resulting programs are bidirectional by construction — 
giving rise to the paradigm of bidirectional programming. 

In this paper, we develop a framework for applicative-style 
and higher-order bidirectional programming, in which we can 
write bidirectional transformations as unidirectional programs in 
standard functional languages, opening up access to the bundle 
of language features previously only available to conventional 
unidirectional languages. Our framework essentially bridges two 
very different approaches of bidirectional programming, namely 
the lens framework and Voigtlander’s semantic bidirectionalization, 
creating a new programming style that is able to bag benefits from 
both. 

Categories and Subject Descriptors D.1.1 [Programming Tech- 
niques]'. Applicative (Functional) Programming; D.3.3 [Program- 
ming Language ]: Languages Constructs and Features — Data types 
and structures, Polymorphism 

General Terms Languages 

Keywords Bidirectional Programming, Lens, Bidirectionalization, 
Free Theorem, Functional Programming, Flaskell 

1. Introduction 

Bidirectionality is a reoccurring aspect of computing: transforming 
data from one format to another, and requiring a transformation in 
the opposite direction that is in some sense an inverse. The most 
well-known instance is the view-update problem [1, 6, 8, 13] from 
database design: a “view” represents a database computed from 
a source by a query, and the problem comes when translating an 
update of the view back to a “corresponding” update on the source. 

But the problem is much more widely applicable than just to 
databases. It is central in the same way to most interactive programs, 
such as desktop and web applications', underlying data, perhaps 
represented in XML, is presented to the user in a more accessible 
format, edited in that format, and the edits translated back in terms 
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of the underlying data [12, 16, 30], Similarly for model transfor- 
mations , playing a substantial role in software evolution: having 
transformed a high-level model into a lower-level implementation, 
for a variety of reasons one often needs to reverse engineer a revised 
high-level model from an updated implementation [42, 43], 

Using terminologies originated from the lens framework [4, 9, 
10], bidirectional transformations, coined lenses, can be represented 
as pairs of functions known as get of type S —t V and put of type 
S — > V — t S. Function get extracts a view from a source, and 
put takes both an updated view and the original source as inputs to 
produce an updated source. An example definition of a bidirectional 
transformation in Haskell notations is 

data L s v — L { get :: s — > v, put :: s — > v — > s } 

fst L :: L (a, b) a 

fst L = L (A (a, _) a) (A(_, 6) a (a, b)) 

A value £ of type L s v is a lens that has two function fields 
namely get and put, and the record syntax overloads the field names 
as access functions: get l has type s — t v and put l has type 
s — > v — > s. The datatype is used in the definition of fst L where 
the first element of a source pair is projected as the view, and may 
be updated to a new value. 

Not all bidirectional transformations are considered "reason- 
able" ones. The following laws are generally required to establish 
bidirectionality: 

put t s ( get £ s) = s (Acceptability) 

get £ s' = v if put £ s v = s' (Consistency) 

for all s, s' and v. Note that in this paper, we write e = e! with 
the assumption that neither e nor e' is undefined. Here Consistency 
(also known as the PutGet law [9] ) roughly corresponds to right- 
invertibility, ensuring that all updates on a view are captured 
by the updated source; and Acceptability (also known as the 
GetPut law [9] ), prohibits changes to the source if no update has 
been made on the view. Collectively, the two laws defines well- 
behavedness [1, 9, 13]. A bidirectional transformation L get put 
is called well-behaved if it satisfies well-behavedness. The above 
example fst L is a well-behaved bidirectional transformation. 

By dint of hard effort, one can construct separately the forward 
transformation get and the corresponding backward transformation 
put. However, this is a significant duplication of work, because the 
two transformations are closely related. Moreover, it is prone to 
error, because they do really have to correspond with each other to 
be well-behaved. And, even worse, it introduces a maintenance issue, 
because changes to one transformation entail matching changes to 
the other. Therefore, a lot of work has gone into ways to reduce this 
duplication and the problems it causes; in particular, there has been 
a recent rise in linguistic approaches to streamlining bidirectional 
transformations [2, 4, 9-11. 14, 16, 20-22, 25, 27, 30, 33, 35, 36, 38- 
41], 
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Ideally, bidirectional programming should be as easy as usual 
unidirectional programming. For this to be possible, techniques of 
conventional languages such as applicative-style and higher-order 
programming need to be available in the bidirectional languages, so 
that existing programming idioms and abstraction methods can be 
ported over. It makes sense to at least allow programmers to treat 
functions as first-class objects and have them applied explicitly. It 
is also beneficial to be able to write bidirectional programs in the 
same style of their gets, as cultivated by traditional unidirectional 
programming programmers normally start with (at least mentally) 
constructing a get before trying to make it bidirectional. 

However, existing bidirectional programming frameworks fall 
short of this goal by quite a distance. The lens bidirectional pro- 
gramming framework [2, 4, 9-11, 16, 25, 27, 30, 38, 39], the most 
influential of all, composes small lenses into larger ones by special 
lens combinators. The combinators preserve well-behavedness, and 
thus produce bidirectional programs that are correct by construction. 
Lenses are impressive in many ways: they are highly expressive and 
adaptable, and in many implementations a carefully crafted type 
system guarantees the totality of the bidirectional transformation. 
But at the same time, like many other combinator-based languages, 
lenses restrict programming to the point-free style, which may not 
be the most appropriate in all cases. We have learned from past 
experiences [23, 28] that a more convenient programming style does 
profoundly impact on the popularity of a language. 

The researches on bidirectionalization [14, 20-22, 33, 35, 36, 
38, 39. 41], which mechanically derives a suitable put from an 
existing get, share the same spirit with us to some extent. The 
gets can be programmed in a unidirectional language and passed 
in as objects to the bidirectionalization engine, which performs 
program analysis and the generation of puts. However, the existing 
bidirectionalization methods are whole program analyses; there is 
no better way to compose individually constructed bidirectional 
transformations. 

In this paper, we develop a novel bidirectional programming 
framework: 

• As lenses, it supports composition of user-constructed bidirec- 
tional transformations, and well-behavedness of the resulting 
bidirectional transformations is guaranteed by construction. 

• As a bidirectionalization system, it allows users to write bidirec- 
tional transformations almost in the same way as that of gets, in 
an applicative and higher-order programming style. 

The key idea of our proposal is to lift lenses of type L (Ai, . . . , A n ) B 
to lens functions of type 

Vs. L s A^ — / * * * / L s A n — / . . . i L s B 

where L T is a type-constrained version of L (Sections 2 and 3). 
The n-tuple above is then generalized to data structures such as 
lists in Section 4. This function representation of lenses is open to 
manipulation in an applicative style, and can be passed to higher- 
order functions directly. For example, we can write a bidirectional 
version of unlines, defined by 

unlines :: [String] —¥ String 
unlines [] = "" 

unlines ( x : xs) = x 4F "\n" 4F unlines xs 
as below. 

unlines f :: [17 s String] —rL r s String 
unlinesp [ ] = new " " 

unlinesF ( x : xs) = Uft2 catLinei. {x, unlinesF xs) 

where catLineh is a lens version of Ax y — > x -H- "\n" 4F y. In the 
above, except for the noise of new and Uft2, the definition is faithful 
to the original structure of unlines’ definition, in an applicative 



style. With the heavy-lifting done in defining the lens function 
unlinesF, a corresponding lens unlines l :: L [String] String is 
readily available through straightforward unlifting: unlinesr, = 
unliftT unlinesF- 

We demonstrate the expressiveness of our system through a 
realistic example of a bidirectional evaluator for a higher-order pro- 
gramming language (Section 5), followed by discussions of smooth 
integration of our framework with both lenses and bidirectional- 
ization approaches (Section 6). We discuss related techniques in 
Section 7, in particularly making connection to semantic bidirection- 
alization [21, 22, 33, 41] and conclude in Section 8. An implemen- 
tation of our idea is available from https : / /hackage . haskell . 
org/package/app- lens. 

Notes on Proofs and Examples. Due to the space restriction, we 
omit many of the proofs in this paper, but note that some of the 
proofs are based on free theorems [34, 37], To simplify the formal 
discussion, we assume that all functions except puts are total and 
no data structure contains _L. To deal with the partiality of puts, we 
assume that a put function of type A — > B — > A can be represented 
as a total function of type A — > B — > Maybe A, which upon 
termination will produce either a value Just a or an error Nothing. 

We strive to balance the practicality and clarity of examples. 
Very often we deliberately choose small but hopefully still illu- 
minating examples aiming at directly demonstrating the and only 
the theoretical issue being addressed. In addition, we include in 
Section 5 a sizeable application and would like to refer interested 
readers to https : / /bitbucket . org/kztk/app- lens for exam- 
ples ranging from some general list functions in Prelude to the 
specific problem of XML transformations. 

2. Bidirectional Transformations as Functions 

Conventionally, bidirectional transformations are represented di- 
rectly as pairs of functions [9, 13, 14, 16, 20-22, 25, 33, 35, 36, 38- 
41] (see the datatype L defined in Section 1). In this paper, we 
use lenses to refer specifically bidirectional transformations in this 
representation. 

Lenses can be constructed and reasoned compositionally. For 
example, with the composition operator “ 6 ” 

(6) :: L b c —r L a b —r L a c 
(L get 2 put 2 ) 6 (L getx put t ) = 

L ( get 2 o get x ) (As v — > put x s ( put 2 (ffefj s) v)) 

we can compose /sf L to itself to obtain a lens that operates on nested 
pairs, as below. 

fstTri L :: L ((a, b), c) a 
fstTri h = /st L 6 /sf L 

Well-behavedness is preserved by such compositions: fstTri h is 
well-behaved by construction assuming well-behaved /sf L . 

The composition operator “6” has the identity lens idi. as its 
unit. 

id-L :: L a a 

idi, — L id (A_ v — > v) 

2.1 Basic Idea: A Functional Representation Inspired by 
Yoneda 

Our goal is to develop a representation of bidirectional transfor- 
mations such that we can apply them, pass them to higher-order 
functions and reason about well-behavedness compositionally. 

Inspired by the Yoneda embedding in category theory [19], we 
lift lenses of type Lab to polymorphic functions of type 

Vs. L s a —¥ L s b 
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by lens composition 

lift :: L a b —3 (Vs. L s a — > Z, s 6) 
lift £ = Xx — > £ 6 a: 

Intuitively, a lens of type L s A with the universally quantified type 
variable s can be seen as an updatable datum of type A, and a lens 
of type L A B as a transformation of type Vs. L s A — > i s B on 
updatable data. We call such lifted lenses lens functions. 

The lifting function lift is injective, and has the following left 
inverse. 

unlift :: (Vs. isa->fsi)-tia!) 
unlift f = f id l 

Since lens functions are normal functions, they can be composed 
and passed to higher-order functions in the usual way. For example, 
fstTri h can now be defined with the usual function composition. 

fstTri L :: L ((a, b), c) a 

fstTri L = unlift ( lift fst L o lift fst L ) 

Alternatively in a more applicative style, we can use a higher-order 
function twice ::(«—■ > a) — > a — > aas below. 

fstTri h — unlift (Xx — > twice ( lift fst L ) x ) 
where twice f x = f (f x) 

Like many category-theory inspired isomorphisms, this func- 
tional representation of bidirectional transformations is not un- 
known [7]; but its formal properties and applications in practical 
programming have not been investigated before. 

2.2 Formal Properties of Lens Functions 

We reconfirm that lift is injective with unlift as its left inverse. 

Proposition 1. unlift ( lift £) = l for all lenses l :: L A B. □ 

We say that a function f presents well-behavedness, if / l is 
well-behaved for any well-behaved lens £. Functions lift and unlift 
have the following desirable properties. 

Proposition 2. lift £ preserves well-beliavedness if £ is well- 
behaved. □ 

Proposition 3. unlift f is well-behaved if f preserves well- 
behavedness. □ 

As it stands, the type L is open and it is possible to define lens 
functions through pattern-matching on the constructor. For example 

/ :: Eq a =$■ L s ( Maybe a) — > L s ( Maybe a) 
f (L g p) = L g (As v -» if v =- g s then s 

else p (p s Nothing) v) 

Flere the input lens is pattern matched and the get/put components 
are used directly in constructing the output lens, which breaks 
encapsulation and blocks compositional reasoning of behaviors. 

In our framework the intention is that all lens functions are 
constructed through lifting, which sees bidirectional transformations 
as atomic objects. Thus, we require that L is used as an “abstract 
type” in defining lens functions of type Vs. L s A — *• L s B. That 
is, we require the following conditions. 

• L values must be constructed by lifting. 

• L values must not be destructed. 

This requirement is formally written as follows. 

Definition 1 (Abstract Nature of L). We say L is abstract in / :: r 
if there is a polymorphic function h of type 

W. (Vfli b. L a b — » (Vs.£ s a, — / £ s b)) 

— y (Va b. (Vs.£ sa—t£sb)—}Lab)—>T' 



where t' = r[£/L\ and / = h lift unlift. □ 

Essentially, the polymorphic £ in ft’s type prevents us from using 
the constructor L directly, while the first functional argument of ft 
(which is lift ) provides the means to create L values. 

Now the compositional reasoning of well-behavedness extends to 
lens functions; we can use a logical relation [31] to characterize well- 
behavedness for higher-order functions. As an instance, we can state 
that functions of type Vs.LsA^LsB are well-behavedness 
preserving as follows. 

Theorem 1. Let f :: Vs. LsA^rLsBbe a function in which L 
is abstract. Suppose that all applications of lift in the definition of 
f are to well-behaved lenses. Then, f preserves well-behavedness, 
and thus unlift f is well-behaved. □ 

2.3 Guaranteeing Abstraction 

Theorem 1 requires the condition that L is abstract in /, which can 
be enforced by using abstract types through module systems. For 
example, in Flaskell, we can define the following module to abstract 
L. 

module AbstractLens (L a bs, lift a bs , unlift a bs ) where 
newtype L a bs a b = L a b s {unL a b s :: L a b} 
lift aba ■.. L a b -¥ (Vs. Labs s a -¥ Labs s b) 
unliftabs ■■ (Vs. Labs s a — > L a b s s b) — > L a b 

Outside the module AbstractLens, we can use lift aba , unlift a b s 
and type Labs itself, but not the constructor of Labs- Thus the only 
way to access data of type L is through lift ab s an d unlift a bs- 

A consequence of having abstract L is that lift is now surjective 
(and unlift is now injective). We can prove the following property 
using the free theorems [34, 37], 

Lemma 1. Let f be a function of type Vs.LsA^LsBin which 
L is abstract. Then f £ = f idv ° £ holds for all £ :: L S A. □ 

Correspondingly, we also have that unlift is injective on lens 
functions. 

Theorem 2. For any f :: Vs. L s A — t L s B in which L is abstract, 
lift ( unlift f)=f holds. □ 

In the rest of this paper, we always assume abstract L unless 
specially mentioned otherwise. 

2.4 Categorical Notes 

As mentioned earlier, our idea of mapping LAB to Vs. is 3-t 
L s B is based on the Yoneda lemma in category theory (Section 
III.2 in [19]). Since our purpose of this paper is not categorical 
formalization, we briefly introduce an analogue of the Yoneda 
lemma that is enough for our discussion. 

Theorem 3 (An Analogue of the Yoneda Lemma (Section III.2 in 
[19])). A pair of functions (lift, unlift) is a bijection between 

• {£ \: L A B}, and 

• {/ :: Vs. LsA^LsB\fxoy=f(xo y)}. □ 

The condition / x 6 y = f (x 6 y) is required to make / a natural 
transformation between functors L (— ) A and L (— ) B\ here, the 
contravariant functor L (—) A maps a lens £ of type L Y X to 
a function (A y —t y o £) of type L X A — > L Y A. Note that 
/ x o y = f (x o y) is equivalent to f x = f idb 6 x. Thus the 
naturality conditions imply Theorem 2. 

In the above, we have implicitly considered the category of 
(possibly non-well-behaved) lenses, in which objects are types 
(sets in our setting) and morphisms from A to B are lenses of 
type LAB. This category of lenses is monoidal [15] but not 
closed [30], and thus has no higher-order functions. That is, there is 
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no type X B C such that there is a bijection between L ( A , B) C 
and L A ( X B C ), which can be easily checked by comparing 
cardinalities. Our discussion does not conflict with this fact. What 
we state is that, for any s, (L s A, L s B) — » L s C is isomorphic 
to L s A — > (L s B — v L s C) via standard curry and uncurry ; 
note that s is quantified globally. 

Also note that L s (— ) is a functor that maps a lens £ to a 
function lift £. It is not difficult to check that lift x o lift y = 
lift ( x o y) and lift ( idh L A A) = (id :: L s A — ► L s A). 

3. Lifting n-ary Lenses and Flexible Duplication 

So far we have presented a system that lifts lenses to functions, 
manipulates the functions, and then “unlifts’" the results to con- 
struct composite lenses. One example is /sfTH L from Section 2 
reproduced below. 

fstTri L :: L ((a, b), c) a 

fstTri h = unlift ( lift fst L o lift fst L ) 

Astute readers may have already noticed the type L ((a, b), c) a 
which is subtly distinct from L (a, b, c) a. One reason for this is 
with the definition of fstTri h , which consists of the composition of 
lifted /si L s. But more fundamentally it is the type of lift {L x y — » 
(Vs. L s x — > L s y)), which treats x as a black box, that has 
prevented us from rearranging the tuple components. 

Let's illustrate the issue with an even simpler example that goes 
directly to the heart of the problem. 

swap L :: L (a, b) ( b , a) 
swap L = . . . 

Following the programming pattern developed so far, we would 
like to construct this lens with the familiar unidirectional function 
swap::(a, b) —y (6, a). But since lift only produces unary functions 
of type Ms.LsA^LsB, despite the fact that A and B are 
actually pair types here, there is no way to compose swap with the 
resulting lens function. 

In order to construct swap L and many other lenses, including 
unlinesh in Section 1, a conversion of values of type Vs. (Is Ai, 

. . . , L s A n ) to values of type Vs. L s (Ai , . . . , A n ) is needed. In 
this section we look at how such a conversion can be defined for 
binary lenses, which can be easily extended to arbitrary n-ary cases. 

3.1 Caveats of the Duplication Lens 

To define a function of type Vs. (L s A, L s B) — » L s (A, B ), we 
use the duplication lens dup h (also known as copy elsewhere [9]) 
defined as below. For simplicity, we assume that (--) represents 
observational equivalence. 

dup L :: Eq s => L s (s, s) 
dnp L = L (As — » (s, s)) (A_ (s, f) — > r s t) 
where rst\s~-t = s -- This will cause a problem. 

With the duplication lens, the above-mentioned function can be 
defined as 

(©) :: Eq s => L s a —y L s b — » L s (a, b) 
x © y = (x 0 y) o dup h 

where (®) is a lens combinator that combines two lenses applying 
to each component of a pair [9]: 

(®) :: L a a' —y L b b' — > L (a, b) (a ' , b') 

( L get 1 put x ) 0 ( L get 2 put 2 ) = 

L (A (a, b) ( get 1 a, get 2 b )) 

(A(a, b) (a 1 , b') — > (put 1 a a' ,put 2 b b')) 

We call (©) “split” in this paper. With (©) we can support the lifting 
of binary lenses as below. 



Iift2 :: L (a, b) c — > (Vs. (L s a, L s b) L s c) 
lift2 £ (x, y) = lift £ (x © y) 

It is tempting to have the following as the inverse for Uft2. 

unliftS :: (Vs. (L s a, L s b) — » L s c) — » L (a, b) c 
unliftS f = f ( fst L , sndif) 

But unliftS o lifts does not result in identity: 

( unliftS o lifts) £ 

= { definition unfolding & /3-reduction j 
£ 6 (/si L © sndif) 

= { unfolding (©) } 

£ 6 (/sf L ® sndif) o dup L 
= { definition unfolding j 
£ 6 blockh where 

blocks = L id (As v — > if s — v then v else _L) 

Lens blocks is not a useful lens because it blocks any update to the 
view. Consequently any lenses composed with it become useless 
too. 

3.2 Flexible and Safe Duplication by Tagging 

In the above, the equality comparison s -- v that makes unliftS o 
lifts useless has its root in dup h . If we look at the lens dup h in 
isolation, there seems to be no alternative. The two duplicated values 
have to remain equal for the bidirectional laws to hold. However, 
if we consider the context in which dup h is applied, there is more 
room for maneuver. Let us consider the lifting function lifts again, 
and how put dup h , which rejects the update above, works in the 
execution of put ( unliftS ( lifts idi, )). 

put ( unlift2 ( lifts idh)) (1,2) (3,4) 

= { simplification ) 

put ((/st L 0 sndh) o dup L ) (1, 2) (3,4) 

= { definition unfolding & /3-reduction ) 

put dup L (1, 2) ( put fst h (1, 2) 3, put sndh (1, 2) 4) 

= { /3 -reduction ) 

put dup h (1,2) ((3,2), (1,4)) 

The last call to put dup h above will fail because (3, 2) ^ (1,4). 
But if we look more carefully, there is no reason for this behavior: 
lifts idB should be able to update the two elements of the pair 
independently. Indeed in the put execution above, relevant values 
to the view change as highlighted by underlining are only compared 
for equality with irrelevant values. That is to say, we should be able 
to relax the equality check in dup h and update the old source (1, 2) 
to (3, 4) without violating bidirectional laws. 

To achieve this, we tag the values according to their relevance to 
view updates [25]. 

data Tag a = U {unTag :: a} \ O { unTag :: a} 

Tag U (representing Updated) means the tagged value may be 
relevant to the view update and O (representing Original) means the 
tagged value must not be relevant to the view update. The idea is that 
O-tagged values can be altered without violating the bidirectional 
laws, as the new dup L below. 

dup h :: Poset s => L s (s, s) 

dup L = L (As —¥ ( s , s)) (A_ (s, t) — > s Y f) 

Here, Poset is a type class for partially-ordered sets that has a 
method (Y ) (pronounced as “lub") to compute least upper bounds. 

class Poset s where (Y) :: s — > s — > s 

We require that (Y) must be associative, commutative and idempo- 
tent; but unlike a semilattice, (Y ) can be partial. Tagged elements 
and their (nested) pairs are ordered as follows. 
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instance Eq a => Poset ( Tag a) where 
(O s) Y (U t) =Ut 

(U s) Y (O t) = U s 

(O s) Y (O t) | s -- t = O s 
(U s)Y(U t) \ s ---- t= U s 
instance ( Poset a, Poset b) => Poset (a, b) where 
(a, b) Y (af b') = (a Y a 1 ,b Y 6') 

We also introduce the following type synonym for brevity. 1 

type L T s a = Poset s => L s a 

As we will show later, the move from L to L T will have implications 
on well-behavedness. 

Accordingly, we change the types of (©), lift, and Uft2 as below. 

(©) :: f T s o -> i T s ii -> £ T s (a, b) 
lift :: L a b — >• (Vs. 17 s a — » 17 s b) 
lift2 :: L (a, b) c — > (Vs. (17 s a, L T s b) — ► L T s c ) 

And adapt the definitions of unlift and unlift2 to properly handle 
the newly introduced tags. 

unlift :: Eq a => (Vs. L T s a — >• L J s b) — » Z, a b 
unlift f = f idf 6 fa# L 
:: £ T ( Tag a) a 
id l = L unTag (const U) 
tag h :: L a ( Tag a) 
tag h = L O ( const unTag) 

unliftS :: (Eq a, Eq b) => 

(Vs. (L T s a, Lf s b) — y 17 s c) — t L (a, b) c 
unliftS f =f (fstf, snd'if) 6 tagS h 
fstf :: 17 (Tag a, Tag b) a 

fst l = L (A (a, _) — > unTag a) (A(_, b) a — > (U a, b)) 
sndf :: 17 (Tag a, Tag b) b 

sndf = L (A(_, b) — > unTag b) (A(a, _) b — > (a, U b )) 
tagS h :: L (a, b) (Tag a, Tag b) 
tagS h = L (A (a, 6) — » (O a, O b)) 

(X- (a, b) — >• (unTag a , unTag b)) 

We need to change unlift because it may be applied to functions 
calling lifts internally. In what follows, we only focus on lifts and 
unlift2, and expect the discussion straightforwardly extends to lift 
and the new unlift. 

We can now show that the new unlift2 is the left-inverse of 
lift2. 

Proposition 4. unlift2 (lift2 £) = £ holds for all lenses £ :: 
L (A, B) C. 

Proof. We prove the statement with the following calculation. 

unlift2 (lift2 £) 

= { definition unfolding & /3-reduction } 

£ 6 fst l © snd' L 6 tag2 h 
= { unfolding (©) } 

£ o (fst’ h 0 snd'if) 6 dup L 6 tag2 h 
~ { (f s t l ® snd'if) 6 dup L 6 tag2 L = idi, — (*) j 
£ 

We prove the statement (*) by showing get ((fst' L 0 snd' L ) 6 
dup h 6 tag2i) (a, b) = (a, b) and put ((fst' L 0 snd’if) ° dup L 6 



1 Actually, we will have to use newtype for the code in this paper to pass 
GHC’s type checking. We take a small deviation from GHC Haskell here in 
favor of brevity. 



tagSif) (a, b) (a' , b') = (a' , b'). Since the former property is easy 
to prove, we only show the latter here. 

put (( fst[ j 0 snd'if) ° dup L 6 tag2jf) (a, b) (af b') 

= { definition unfolding & /3-reduction j 

put tagS h (a, b) $ 

put ((fstf 0 snd'if) ° dup if) (O a, O b) (a' , b 1 ) 

= { definition unfolding & /3-reduction j 
put tagS h (a, b) $ 
put dup h (O a, O b) $ 

(put fstf (O a, O b) a', put sndf (O a, O b) b') 

= { definitions of fst' L and sndf } 
put tagS h (a, b) $ 

put dup L (O a, O b) ((U a' , O b), (O a, U b ')) 

= { definition of dup L } 

put tagS h (a, b) (U a',U b') 

= { definition of tag2 h J 
(af b’) 

Thus, we have proved that Uft2 is injective. □ 

We can recreate fst L and sndi, with unliftS, which is rather 
reassuring. 

Proposition 5. fst L = unlift2 fst and snd l = unlift2 snd. □ 

Note that now unlift and unlift2 are no longer injective (even 
with abstract L): there exist functions that are not equivalent but 
coincide after unlifting. An example of such is the pair lifts fst L and 
fst: while unlifting both functions result in fst L , they actually differ 
as put (lift2 fst L (fstf, snd'if)) (O a, O b) c = (U c, U b) and 
put (fst (fstf, snd'if)) (O a, O b) c = (U c, O b). Intuitively, 
fst knows that the second argument is unused, while Uft2 fst L 
does not because /st L is treated as a black box by Uft2. In other 
words, the relationship between the lifting/unlifting functions and 
the Yoneda Lemma discussed in Section 2 ceases to exist in this 
new context. Nevertheless, the counter-example scenario described 
here is contrived and will not affect practical programming in our 
framework. 

Another side effect of this new development with tags is that 
the original bidirectional laws, i.e., the well-behavedness, are tem- 
porarily broken during the execution of Uft2 and unlift2 by the new 
internal functions fstf, sndf, dup h and tag2 L . Consequently, we 
need a new theoretical development to establish the preservation of 
well-behavedness by the lifting/unlifting process. 

3.3 Relevance-Aware Well-Behavedness 

We have noted that the new internal functions dup h , fstf, sndf and 
tag2 L are not well-behaved, for different reasons. For functions fst' L 
and sndf, the difference from the original versions fst h and sndc is 
only in the additional wrapping/unwrapping that is needed to adapt 
to the existence of tags. As a result, as long as these functions are 
used in an appropriate context, the bidirectional laws are expected 
to hold. But for dup h and tag2 L , the new definitions are more 
defined in the sense that some originally failing executions of put 
are now intentionally turned into successful ones. For this change in 
semantics, we need to adapt the laws to allow temporary violations 
and yet still establish well-behavedness of the resulting bidirectional 
transformations in the end. For example, we still want unlift2 f to 
be well-behaved for any / :: Vs. (L T s A, L T s B) — > L T s C, as 
long as the lifting functions are applied to well-behaved lenses. 

3.3.1 Relevance-Ordering and Lawful Duplications 

Central to the discussion in this and the previous subsections is the 
behavior of dup L . To maintain safety, unequal values as duplications 
are only allowed if they have different tags (i,e,. one value must be 
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irrelevant to the update and can be discarded). We formalize such 
a property with the partial ordering between tagged values. Let us 
write (X) for the partial order induced from Y: that is, s Y t if 
s Y t is defined and equal to t. One can see that (Y) is the reflexive 
closure of O s Y U t. We write 'fs for a value obtained from s by 
replacing all O tags with U tags. Trivially, we have s Y fs. But 
there exists s' such that s Y s' and s' 'fs. 

Now we can define a variant of well-behavedness local to the 
U -tagged elements. 

Definition 2 (Local Well-Behavedness). A bidirectional transfor- 
mation £ :: L T a b is called locally well-behaved if the following 
four conditions hold. 

• (Forward Tag-Irrelevance) If v = get t s, then for all s' such 
that = t s > v — get (■ s ' holds. 

• (Backward Inflation) For all minimal (with respect to Y) s, if 
put Is v succeeds as s', then s Y s'. 

• (Local Acceptability) For all s, s Y put £ s ( get Is) Y fs. 

• (Local Consistency) For all s and v, assuming put £ s v 

succeeds as s', then for all s" with s' Y s", get £ s" = v 
holds. □ 

In the above, tags introduced for the flexible behavior of put 
must not affect the behavior of get: ts' = means that s and 
s' are equal if tags are ignored. The property local-acceptability is 
similar to acceptability, except that O-tags are allowed to change to 
U -tags. The property local consistency is stronger than consistency 
in the sense that get must map all values sharing the same U - 
tagged elements with s' to the same view. The idea is that O-tagged 
elements in s' are not connected to the view v, and thus changing 
them will not affect v. A similar reasoning applies to backward 
inflation stating that source elements changed by put will have U - 
tags. Note that in this definition of local well-behavedness, tags are 
assumed to appear only in the sources. As a matter of fact, only 
dup h and tag2 h /tag h introduce tagged views; but they are always 
precomposed when used, as shown in the following. 

We have the following compositional properties for local well- 
behavedness. 

Lemma 2. The following properties hold for bidirectional transfor- 
mations x and y with appropriate types. 

• Ifx is well-behaved and y is locally well-behaved, then lift x y 
is locally well-behaved. 

• If x and y are locally well-behaved, x © y is locally well- 
behaved. 

• Ifx and y are locally well-behaved, x 6 tag2 L and y 6 tag h are 
well-behaved. 

Proof. We only prove the second property, which is the most non- 
trivial one among the three, although we would like to note that 
forward tag-irrelevance is used to prove the third property. 

We first show local acceptability. 

put ((x 0 y) o dup L ) s ( get ((x 0 y) 6 dup h ) s) 

= { simplification ) 

put dup h s ( put (x 0 y) (s, s) ( get ( x 0 y) (s, s))) 

= { by the local acceptability of x 0 y ) 

put dup h s (s ' , s") — where s Y s' Y fs, s Y s” Y "(s 
= { by the definition of dup L and that s' Y s" is defined } 
s' Y s" Y fs 

Note that, since s' Y 'fs and s" Y fs, there is s' Y s" Y -fs. 

Then, we prove local consistency. Assume that put ((x 0 y) 6 
dup L ) s (t»i, V 2 ) succeeds in s' . Then, by the following calculation, 
we have s' = put x s Vi Y put y s V 2 . 



put ((® 0j/) 6 dup h ) s (vi, v 2 ) 

— { simplification } 

put dup L s ( put x s vi,put y s V 2 ) 

= { definition unfolding ) 
put x s vi Y put y s V 2 

Let s" be a source such that s' Y s" . Then, we prove get ((x 0 
y)@dup L ) s" = (vi, V 2 ) as follows. 

get ((x 0 y) 6 dup h ) s" (vi,V 2 ) 

= { simplification ) 

(get x s",get y s") 

= { the local consistency of x and y } 

(V1,V2) 

Note that we have put x s vi Y s' Y s" and put y s V 2 Y s' Y 
s" by the definition of Y. 

Forward tag-irrelevance and backward inflation are straightfor- 
ward. □ 

Corollary 1 . The following properties hold. 

• lift £::\/s. L T s A -A L T s B preserves local well-behavedness, 
if£ :: If A B is well-behaved. 

• lift2 £ :: Vs. (17 s A, 17 s B) — y 17 s C presents local 

well-behavedness, if£ :: 17 (A, B) C is well-behaved. □ 

Similar to the case in Section 2, compositional reasoning of 
well-behavedness requires the lens type 17 to be abstract. 

Definition 3 (Abstract Nature of 17). We say 17 is abstract in / :: r 
if there is a polymorphic function h of type 

\/£. (Vfli b. 17 a b — > (Vs. £ s a £ s b)) 

—¥ (Va b. ( 7s.£ s a —¥ l s b) 17 a b) 

—¥ (Vs a b.£ s a —y £ s b — > l s (a, b)) 

—t (Va b c. (Vs. (£ s a, £ s b) — » £ x c) — > 17 (a, b) c) 

-A t' 

satisfying f = h lift unlift (©) unlift2 and r = t[£/L t ]. □ 

Then, we obtain the following properties from the free theo- 
rems [34, 37], 

Theorem 4. Let f be a function of type Vs. (L T s A, L T s B) — >■ 
L T s C in which L T is abstract. Then, f (x, y) is locally well- 
behaved ifx and y are also locally well-behaved, assuming that lift 
is applied only to well-behaved lenses. □ 

Corollary 2. Let f be a function of type Vs. (L T s A, L T s B) — >■ 
L T s C in which L 1 is abstract. Then, unlift2 f is well-behaved, 
assuming that lift is applied only to well-behaved lenses. □ 

Example 1 (swap). The bidirectional version of swap can be 
defined as follows. 

swap L :: (Eq a, Eq b) => L (a, b) (b, a) 
swap L = unlift2 (lift2 idh ° swap) 

And it behaves as expected. 

put swap L (1,2) (4,3) 

= { unfold definitions J 

put ((snd^ 0 fst l) 6 dup L o tag2 l f) (1,2) (4, 3) 

= { simplifications } 
put tag2 lj (1, 2) $ 
put dup h (O 1, O 2) $ 

(put snd' L (O 1, O 2) 4, put fst' L (O 1, O 2) 3) 

= { definition of fst' h and snd ' L ) 
put tag2 lj (1, 2) $ 

put dup L (O 1, O 2) ((O 1, U 4), (U 3, O 2)) 
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= { definitions of dup L and tag2 h } 

(3,4) □ 

It is worth mentioning that (©) is the base for “splitting" and 
“lifting" tuples of arbitrary arity. For example, the triple case is as 
follows. 

splits :: (17 s a, 17 s b, 17 s c) 17 s (a, b, c) 
splits ( x , y, z) = lift flattenL h (( x © y) © z) 
where flattenL L :: L ((a, b), c) (a, b , c) 

flattenL h = L (X((x, y), z) -s- ( x , y, z)) 

(X- ( x,y,z ) ->■ ((x,y),z)) 

lifts it — lift l ( splits t) 

For the family of unlifting functions, we additionally need n-ary ver- 
sions of projection and tagging functions, which are straightforward 
to define. 

In the above definition of splits, we have decided to nest to the 
left in the intermediate step. This choice is not essential. 

splits' (x, y, z) = lift flattenR h (x © (y © z)) 
where flattenR h :: L ((a, b), c) (a, b, c) 

flattenR L = L (\(x, (y, z)) -»■ (x, y, z)) 

(A- (x, y, z) —t (x,(y,z))) 

The two definitions split3 and splits' coincide. 

To complete the picture, the nullary lens function 

unit :: Vs. 17 s () 

unit = L (A_ — > ()) (As () — > s) 

is the unit for (©). Theoretically (17 s (—), ©, unit) forms a lax 
monoidal functor (Section XI.2 in [19]) under certain conditions 
(see Section 3.4). Practically, unit enables us to define the following 
combinator. 

new :: Eq a => a — > Vs. 17 s a 

new a = lift (L (const a) (A_ a' — > check a a')) unit 

where 

check a a' = if a — a' then () 

else error "Update on constant" 

Function new lifts ordinary values into the bidirectional transfor- 
mation system; but since the values are not from any source, they 
are not updatable. Nevertheless, this ability to lift constant values 
is very useful in practice [21, 22], as we will see in the examples to 
come. 

3.4 Categorical Notes 

Recall that L S (— ) is a functor from the category of lenses to the 
category of sets and (total) functions, which maps l :: L A B to 
lift i:: L S A L S B for any S. In the case that S is tagged and 
thus partially ordered, (17 S (—),©, unit ) forms a lax monoidal 
functor, under the following conditions. 

• (©) must be natural, i.e., (lift f x) © (lift g y) = lift (f ® 
g) (x © y) for all /, g, x and y with appropriate types. 

• splits and splits' coincide. 

• lift elimUnitLh (unit®x) = a; must hold where elimUnitLc :: 
L ((), a) a is the bidirectional version of elimination of (), and 
so does its symmetric version. 

Intuitively, the second and the third conditions state that the mapping 
must respect the monoid structure of products, with the former 
concerning associativity and the latter concerning the identity 
elements. The first and second conditions above hold without any 
additional assumptions, whereas the third condition, which reduces 
to s Y put x s v = put x s v, is not necessarily true if s 



is not minimal (if s is minimal, this property holds by backward 
inflation). Recall that minimality of s implies that s can only have 
O-tags. To get around this restriction, we take 17 S A as a quotient 
set of L S A by the equivalence relation = defined as x = y if 
get x = get y A put x s — put y s for all minimal s. This 
equivalence is preserved by manipulations of //-data; that is, the 
following holds for x, y, z and w with appropriate types. 

• x = y implies lift l x = lift l y for any well-behaved lens l. 

• x = y and z = w implies x © z = y © w. 

• x = y implies x 6 tag L = y 6 tag h (or x 6 tag2 h = y 6 tag2 l f). 

Note that the above three cases cover the only ways to con- 
struct/destruct 17 in / when 17 is abstract. The third condition 
says that this “coarse” equivalence (=) on 17 can be “sharpened” 
to the usual extensional equality (=) by tag L and tag2 L in the 
unlifting functions. 

It is known that an Applicative functor in Haskell corresponds to 
a monoidal functors [29]. However, we cannot use an Applicative- 
like interface because there is no exponentials in lenses [30], Never- 
theless, the same spirit of applicative-style programming centering 
around lambda abstractions and function applications is shared in 
our framework. 

4. Going Generic 

In this section, we make the ideas developed in previous sections 
practical by extending the technique to lists and other data structures. 

4.1 Unlifting Functions on Lists 

We have looked at how unlifting works for n-nary tuples in Section 3. 
And we now see how the idea can be extended to lists. As a typical 
usage scenario, if we apply map to a lens function lift l, we will 
obtain a function of type map (lift €) :: [17 s A] — > [17 s B\. But 
what we really would like is a lens of type L [A] [ B(\, The way to 
achieve this is to internally treat length-n lists as n-ary tuples. This 
treatment effectively restricts us to in-place updates of views (i.e., 
no change is allowed to the list structure); we will revisit this issue 
in more detail in Section 6. 1 . 

First, we can “split” lists by repeated pair-splitting, as follows. 

lsequence liat :: [17 s a] — > 17 s [a] 

lsequence Uat [] = lift nili, unit 

lsequence hst (x : xs) = lift2 consh (x, lsequence list xs) 

niR = L( A()— ►[]) (A() []->()) 

cons l = L (A (a, as) —> (a : as)) 

(A_ (a' : as') —> (a', as')) 

The name of this function is inspired by sequence in Haskell. Then 
the lifting function is defined straightforwardly. 

lift list L [a] b — > Vs. [17 s a] — * 17 s b 
lift liBt i xs = lift t (lsequence list xs) 

Tagged lists form an instance of Poset. 

instance Poset a => Poset [a] where 
xs Y ys = if length xs — length ys 
then zipWith (Y) xs ys 
else _L -- Unreachable in our framework 

Note that the requirement that xs and ys must has the same shape 
is made explicit above, though it is automatically enforced by the 
abstract use of 17 in lifted functions. 

The definition of unlift list is a bit more involved. What we need 
to do is to turn every element of the source list into a projection lens 
and apply the lens function /. 
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unlift liat :: Va b. Eq a => 

(Vs. [ £ T s a] — * i T s b) — * £ [a] b 
unlift hat f = L (As — > get ( mkLens s) s) 

(As — > put ( mkLens s) s) 

where 

mkLens s = f ( projs ( length s)) 6 tag List L 

tagList L = £ (map O) (A_ j/s — ► map unTag ys ) 

projs n = map proj h [0 . . n — 1] 

proj h :: Int — > L T [Tag a] a 

proj L i = £ (A®s — > unTag ( xs !! i)) 

(A as a — > update i (U a) as) 

Giving that the need to inspect the length of the source leads to the 
separated definitions of get and put in the above, there might be 
worry that we may lose the guarantee of well-behaveness of the 
resulting lens. But this is not a problem here since the length of 
the source list is an invariant of the resulting lens. Similar to lifts, 
lift tist i s an injection with unlift hst as its left inverse. 

Example 2 (Bidirectional tail). Let us consider the function tail. 

tail :: [a] — > [a] 
tail ( x : xs) = xs 

A bidirectional version of tail is easily constructed by using 
lsequence liat and unlift hat as follows. 

tattle :: Eq a => £ [a] [a] 

taih, = unlift list ( lsequence liat o tail) 

The obtained lens tailh supports all in-place updates, such as 
put taih, ["a", "b", "c") ["B","C"] = ["a", "B", "C"]. In 
contrast, any change on list length will be rejected; specifically 
nilr, or consh in lsequence list throws an error. □ 

Example 3 (Bidirectional unlines). Let us consider a bidirec- 
tional version of unlines :: [String] —¥ String that concatenate 
lines, after appending a terminating newline to each. For example, 
unlines ["ab","c"] = "ab\nc\n". In conventional unidirectional 
programming, one can implement unlines as follows. 

unlines [] = "" 

unlines (x : xs) = catLine x ( unlines xs) 

catLine x y = x 4F "\n" -H- y 

To construct a bidirectional version of unlines , we first need a 
bidirectional version of catLine. 

catLinei. L ( String , String) String 
catLine^ = 

L (A(s, t) — y s -H- "\n" -H- t) 

(A (s, t) u —¥ let n = length ( filter ’ \n’) s) 

i = elemlndices ’\n’ u !! n 
(s ' , t') = splitAt i u 
in (s' , tail t')) 

ITere, elemlndices and splitAt are functions from Data. List: 
elemlndices c s returns the indices of all elements that are equal 
to c; splitAt i x returns a tuple where the first element is x’s 
prefix of length i and the second element is the remainder of the list. 
Intuitively, put catLine l (s, t) u splits u into s' and "\n" -H- t' 
so that s' contains the same number of newlines as the original 
s. For example, put catLine l ("a\nbc", "de") "A\nB\nC" = 
("A\nB", "C"). 

Then, construction of a bidirectional version unlinesi. of 
unlines is straightforward; we only need to replace " " with new " " 
and catLine with Uft2 catLine l, and to apply unlift list to obtain 
a lens. 



unlinesh :: L [ String ] String 
unlinesL = unlift list unlinesF 

unlinesp :: Vs. [£ T s String] — » £ T s String 
unlinesF [ ] = new " " 

unlinesF (x : xs) = lift2 catLine-c (x, unlinesF xs) 

As one can see, unlines f is written in the same applicative style 
as unlines. The construction principle is: if the original function 
handles data that one would like update bidirectionally (e.g., String 
in this case), replace the all manipulations (e.g., catLine and "") 
of the data with the corresponding bidirectional versions (e.g., 
Iift2 catLinei. and new "")• 

Lens unlinesF accepts updates that do not change the original 
formatting of the view (i.e., the same number of lines and an empty 
last line). For example, we have put unlinesi. ["a", "b", "c"] 

" AA\nBB\nCC\n" = ["AA", "BB", "CC"], but put unlinesF 
["a", "b", "c"j "AA\nBB\n" = _L and put unlinesF ["a","b", 
"c"] " AA\nBB\nCC\nD 11 = ±. 

Example 4 ( unlines defined by foldr). Another common way to 
implement unlines is to use foldr, as below. 

unlines = foldr catLine " " 

The same coding principle for constructing bidirectional versions 
applies. 

unlinesh :: L [String] String 
unlinesc, = unlift list unlines f 

unlinesF Vs. [£ T s String] —t £ T s String 
unlinesF = foldr (lift2 catLine l) (new "") 

The new unlines f is again in the same applicative style as the 
new unlines, where the unidirectional function foldr is applied to 
normal functions and lens functions alike. □ 

For readers familiar with the literature of bidirectional transfor- 
mation, this restriction to in-place updates is very similar to that 
in semantic bidirectionalization [21, 33, 41]. We will discuss the 
connection in Section 7.1. 

4.2 Datatype-Generic Unlifting Functions 

The treatment of lists is an instance of the general case of container- 
like datatypes. We can view any container with n elements as an n- 
tuple, only to have list length replaced by the more general container 
shape. In this section, we define a generic version of our technique 
that works for many datatypes. 

Specifically, we use the datatype-generic function traverse, 
which can be found in Data. Traversable, to give data-type 
generic lifting and unlifting functions. 

traverse :: (Traversable t, Applicative f) 

=> (a f b) t a —t f (t b) 

We use traverse to define two functions that are able to extract 
data from the structure holding them (contents), and redecorate an 
“empty” structures with given data (fill). 2 

newtype Const a b = Const {getConst :: a} 

contents :: Traversable t => t a — > [a] 

contents t = getConst (traverse (Xx — > Const [®]) t) 



2 In GHC, the function contents is called toList, which is defined in 
Data. Foldable (Every Traversable instance is also an instance of 
Foldable). We use the name contents to emphasize the function's role 
of extracting contents from structures [3] . 
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fill :: Traversable t => t b — » [a] — > t a 
fill t £ = evalState (traverse next t ) l 

where 

next _ = do (a : x) <— Control. Monad. State. get 
Control. Monad. State. put x 
return a 

Here, Const a b is an instance of the Haskell Functor that ignores 
its argument b. It becomes an instance of Applicative if a is an 
instance of Monoid. We qualified the state monad operations get 
and put to distinguish them from the get and put as bidirectional 
transformations. 

For many datatypes such as lists and trees, instances of 
Traversable are straightforward to define to the extend of being 
systematically derivable [23]. The instances of Traversable must 
satisfy certain laws [3]; and for such lawful instances, we have 

fill ( fmap f t) ( contents t) = t (FillContents) 

contents ( fill t xs) = xs if length xs = length (contents t) 

(ContentsFill) 

for any / and t, which are needed to established the correctness of 
our generic algorithm. Note that every Traversable instance is also 
an instance of Functor. 

We can now define a generic Isequence function as follows. 

Isequence :: (Eq a, Eq (t ()), Traversable t) => 
t (U s a)^L T s(t a) 

Isequence t = 

lift (fill h (shape t)) (lsequence list (contents t)) 

where 

fill h s — L (A xs —¥ fill s xs) (A_ t — > contents' s t) 
contents' s t = if shape t -= s 
then contents t 
else error "Shape Mismatch" 

Here, shape computes the shape of a structure by replacing elements 
with units, i.e., shape t = fmap (A_ — > ()) t. Also, we can make 
a Poset instance as follows. 3 

instance (Poset a, Eq (t ()), Traversable t) => 

Poset (t a) where 
fi y t 2 = if shape ti -= shape t 2 

then fill ti (contents h Y contents ti) 
else _L -- Unreachable, in our framework 

Following the example of lists, we have a generic unlifting function 
with length replaced by shape. 

unliftT :: (Eq (t ()),Eq a, Traversable t) => 

(Vs. t (L7 s a) — » 17 s b) — » L (t a) b 
unliftT f = L (As — > get (mkLens s) s) 

(As — >• put (mkLens s) s) 

where 

mkLens s = f (projTs (shape s)) 6 tagT L 
tagT L = L (fmap O) (const $ fmap unTag) 
projTs sh — 

let n = length (contents sh) 
in fill sh [ projT L i sh \ it— [0 . . n — 1]] 
projT ^ i sh = 

L (unTag o (!!i) o contents) 

(As v — » fill sh (update i (U v) (contents s))) 



3 This definition actually overlaps with that for pairs. So we either need to 
have “wrapper” type constructors, or enable Overlappinglnstances. 



Here, projT L it is a bidirectional transformation that extracts the 
ith element in t with the tag erased. Similarly to unlift hst , the shape 
of the source is an invariant of the derived lens. 

5. An Application: Bidirectional Evaluation 

In this section, we demonstrate the expressiveness of our framework 
by defining a bidirectional evaluator in it. As we will see in a larger 
scale, programming in our framework is very similar to what it is in 
conventional unidirectional languages, distinguishing us from the 
others. 

An evaluator can be seen as a mapping from an environment 
to a value of a given expression. A bidirectional evaluator [14] 
additionally takes the same expression but maps an updated value of 
the expression back to an updated environment, so that evaluating 
the expression under the updated environment results in the value. 

Consider the following syntax for a higher-order call-by- value 
language. 

data Exp = ENum Int \ EInc Exp 

EVar String \ EApp Exp Exp 
EFun String Exp deriving Eq 
data Val a = VNum a 

| VFun String Exp (Env a) deriving Eq 
data Env a = Env [(String, Val a)] deriving Eq 

This definition is standard, except that the type of values is pa- 
rameterized to accommodate both Val (L 1 s Int) and Val Int 
for updatable and ordinary integers, and so does the type of en- 
vironments. It is not difficult to make Val and Env instances of 
Traversable. 

We only consider well-typed expressions. Using our framework, 
writing a bidirectional evaluator is almost as easy as writing the 
usual unidirectional one. 

eval :: Env (L T s Int) — > Exp — > Val (17 s Int) 
eval env (ENum n) = VNum (new n) 

eval env (EInc e) = let VNum v = eval env e 

in VNum (lift inc l v ) 
eval env (EVar x) = Ikup x env 
eval env (EApp ei d) = let VFun x e' (Env env') = 

eval env ei 
V 2 = eval env e 2 
in eval (Env ((a:, V 2 ) : env')) e! 
eval env (EFun x e) = VFun x e env 

Here, incL :: L Int Int is a bidirectional version of (+1) that can 
be defined as follows. 

mcL = L (+1) (A_ x — > x — 1) 

and Ikup :: String — » Env a — > a is a lookup function. 

A lens evah, :: Exp — > L (Env Int) ( Val Int) naturally arises 
from eval. 

eval-L :: Exp — » L (Env Int) ( Val Int) 

evalh e = unliftT (A env — > UftT idh $ eval env e) 

As an example, let’s consider the following expression which 
essentially computes x + 65536 by using a higher-order function 
twice in the object language. 

expr = twice @0 twice @@ twice @@ twice @@ inc @@ x 

where 

twice = EFun "f " $ EFun "x" $ 

EVar "f " @@ (EVar "f " @@ EVar "x") 
x = EVar "x" 

inc = EFun "x" $ EInc (EVar "x") 
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infixl 9 <30 -- 60 is left associative 

(@@) = EApp 

For easy reading, we translate the above expression to Haskell 
syntax. 

expr = ((((twice twice ) twice) twice ) inc) x 
where twice f x = f (f x); inc x = x + 1 

Now giving an environment that binds the free variables x and y, 
we can run the bidirectional evaluator as follows, with env o = 
Env [("x", VNum 3)]. 

Main> get (evalc expr) envo 
VNum 65539 

Main> put (evalc expr) envo (VNum 65536) 

Env [("x", VNum 0)] 

As a remark, this seemingly innocent implementation of evalc 
is actually highly non-trivial. It essentially defines compositional (or 
modular) bidirectionalization [20, 21, 33, 41] of programs that are 
monomorphic in type and use higher-order functions in definition — 
something that has not been achieved in bidirectional-transformation 
research so far. 

6. Extensions 

In this section, we extend our framework in two dimensions: al- 
lowing shape changes via lifting lens combinators, and allowing 
(L T s A)-values to be inspected during forward transformations 
following our previous work [21, 22], 

6.1 Lifting Lens-Combinators 

An advantage of the original lens combinators [9] (that operate 
directly on the non-functional representation of lenses) over what 
we have presented so far is the ability to accept shape changes to 
views. We argue that our framework is general enough to easily 
incorporate such lens combinators. 

Since we already know how to lift/unlift lenses, it only takes 
some plumbing to be able to handle lens combinators, which are 
simply functions over lenses. For example, for combinators of type 
L A B ^ L C D we have 

liftC :: Eq a =>■ (L a b — > L c d) —¥ 

(Vs. L T s a — » L T s b) — » (Vt. L 1 t c —¥ L T t d) 
liftC c f = lift (c (unlift /)) 

To draw an analogy to parametric higher-order abstract syn- 
tax [5], the polymorphic arguments of the lifted combinators rep- 
resent closed expressions; for example, a program like \x — > 

. . . c (... x ...).. . does not type-check when c is a lifted combi- 
nator. 

As an example, let us consider the following lens combinator 
mapDefault c . 

mapDefault c :: a — > L a b — > L [a] [6] 
mapDefault c d £ = L (map (get £)) (As v — » go s v) 

where go ss [] = [] 

go [] (v : vs) = put £ d v : go [\ vs 

go (s : ss) (v : vs) = put £ s v : go ss vs 

When given a lens on elements, mapDefault c d turns it into 
a lens on lists. The default value d is used when new elements 
are inserted to the view, making the list lengths different. We can 
incorporate this behavior into our framework. For example, we can 
use mapDefault c as the following, which in the forward direction 
is essentially map (uncurry (+)). 

mapAdd h :: L [(Int, Int )] [Int] 
mapAdd L = unlift mapAdd F 



mapAdd F xs = map F (0, 0) (lift addL) xs 
map F d = liftC (mapDefault c d) 

addL = L (X(x, y) — » x + y) (X(x, _) v — > (x, v — x)) 

This lens mapAdd F constructed in our framework handles shape 
changes without any trouble. 

Main> put mapAdd F [(1, 1), (2, 2)] [3,5] 

[(1.2), (2, 3)] 

Main> put mapAdd h [(1, 1), (2, 2)] [3] 

[(i-2): 

Main> put mapAdd h [(1, 1), (2, 2)] [3,5,7] 

[(1,2), (2, 3), (0,7)] 

The trick is that the expression map F (0,0) (lift addL) 
has type \/s.L T s [(Int, Int)} — » L T s [Int], where the 
list occurs inside L T s, contrasting to map (lift addL)’s type 
Vs. [L 1 s (Int, Int)] — » [ L T s Int], Intuitively, the type construc- 
tor If s can be seen as an updatability annotation; L T s [ (Int , Int ) ] 
means that the list itself is updatable, whereas [ L T s (Int, Int)] 
means that only the elements are updatable. Here is the trade-off: 
the former has better updatability at the cost of a special lifted lens 
combinator; the latter has less updatability but simply uses the usual 
map directly. Our framework enables programmers to choose either 
style, or anywhere in between freely. 

This position-based approach used in mapDefault c is not 
the only way to resolve shape descrepencies. We can also match 
elements according to keys [2, 1 1]. As an example, let us consider a 
variant of the map combinator. 

mapByKey c :: Eq k =>■ a — >• L a b — » L [(fc, a)] [(k, 6)] 
mapByKey c d £ = L (map (X (k, s) —t (k, get £ s))) 

(As v —> go s v) 
where go ss [] = [] 

go ss ((k, v) : vs) = 
case lookup k ss of 
Nothing —t (k,put £ d v) : go ss vs 
Just s —¥ (k,put £ s v) : go (del k ss) vs 
del k [] = [] 

del k ((k' , s) : ss) | k -- k! = ss 

| otherwise = (k' , s) : del k ss 

Lenses constructed with mapByKey c match with keys instead 
of positions. 

mapAddByKey L :: Eq k => L [(&, (Int, Int))] [ (Ar, Int)] 
mapAddByKey F = unlift mapAddByKey F 
mapAddByKey F xs = mapByKey F (0,0) (lift addL) xs 
mapByKey F d = liftC (mapByKey c d) 

Let s be [("A", (1, 1)), ("B", (2, 2))]. Then, the obtained lens 
works as follows. 

Main> put mapAddByKey h s [ ( "B" , 5), ("A", 3)] 

[("B", (2, 3)), ("A", (1,2))] 

Main> put map AddByKey L s [("A", 3)] 

[("A", (1,2))] 

Main> put mapAddByKey F s [ ( "B" , 5), ("C", 7), ("A", 3)] 
[("B", (2, 3)), ("C", (0,7)), ("A", (1,2))] 

6.2 Observations of Lifted Values 

So far we have programmed bidirectional transformations ranging 
from polymorphic to monomorphic functions. For example, unlines 
is monomorphic because its base case returns a String constant, 
which is nicely handled in our framework by the function new. At 
the same time, it is also obvious that the creation of constant values is 
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not the only cause of a transformation being monomorphic [21, 22]. 
For example, let us consider the following toy program. 4 

bad (x, y) = if x -= new 0 then (x, y) else (x, new 1) 

In this program, the behavior of the transformation depends on the 
“observation" made to a value that may potentially be updated in the 
view. Then the naively obtained lens badi, = unlift2 ( liftZ id^ ° 
bad) would violate well-behavedness, as put bad l (0, 2) (1, 2) = 
(1, 2) but get bad^ (1, 2) = (1, 1). 

Our previous work [21, 22] tackles this problem by using a 
monad to record observations, and to enforce that the recorded 
observation results remain unchanged while executing put. The 
same technique can be used in our framework, and actually in a 
much simpler way due to our new compositional formalization. 

newtype R s a = R ( Poset s =>■ s — > (a, s — ¥ Bool)) 

We can see that R A B represents gets with restricted source 
updates: taking a source s :: A, it returns a view of type B together 
with a constraint of type A — > Bool which must remain satisfied 
amid updates of s. Formally, giving R m :: R A B, for any s, if 
(_, p) = m s then we have: (1) p s = True', (2) p s' = True 
implies m s = m s' for any s' . It is not difficult to make R s an 
instance of Monad — it is a composition of Reader and Writer 
monads. We only show the definition of (>=). 

R m >=/ = R. $ As — > let (x, ci ) = m s 

(y, C 2 ) = let R k = f x in k s 
in (y, Xs — > ci s A C 2 s) 

Then, we define a function that produces R values, and a version 
of unlifting that enforces the observations gathered. 

observe :: Eq w => L T s w —¥ R s w 

observe £ = R (As — > let w = get £ s 

in ( w , Xs' —> get £ s' -- w )) 

unliftM2 :: ( Eq a, Eq b) => 

(Vs. (17 s a, 17 s b) Rs (17 s c)) 

— ^ L (a, b) c 

unliftM2 f = L (Xs —¥ get (mkLens f s) s) 

(Xs —¥ put (mkLens f s) s) 

where 

mkLens f s = 

let (£, p) = let R m = f (fst' h , snd' h ) 
in m (get tag2 L s) 

£' = £6 tag2 h 

put' s v = let s' = put £’ s v 

in if p (get tag2 L s') then s' else _L 
in L (get £') put ' 

Although we define the get and put components of the resulting 
lens separately in unliftM2, well-behavedness is guaranteed as 
long as R and L T are used abstractly in /. Note that, similarly 
to unliftM2, we can define unliftM and unliftMT, as monadic 
versions of unlift and unliftT. 

We can now sprinkle observe at where observations happens, 
and use unliftM to guard against changes to them. 

good ( x , y) = fmap (Uft2 id l) $ do 
b <— lift02 (--) x (new 0) 
return (if b then (x, y) else (x, new 1)) 

Here, Uft02 is defined as follows. 



4 This code actually does not type check as (--) on (L7 s Jnt)-values 
depends on a source and has to be implemented monadically. But we do not 
fix this program as it is meant to be a non-solution that will be discarded. 



Uft02 :: Eq w => 

(a — i b — ^ w) — / L s a — ^ L s b — i R s w 

lift02 p x y = liftO (uncurry p) (x ® y) 

UftO :: Eq w => (a — » w) — » L7 s a — ► R s w 
liftO p x = observe (lift (L p unused) x) 
where unused sv\v==ps = s 

Then the obtained lens good L = unliftM2 good successfully 
rejects illegal updates, as put good h (0, 2) (1,2) = ±. 

One might have noticed that the definition of good is in the 
Monadic style — not applicative in the sense of [23], This is necessary 
for handling observations, as the effect of (R s) must depend on the 
value in it [18]. 

Due to space restriction, we refer interested readers to our 
previous work [21, 22] for practical examples of bidirectional 
transformations with observations. 

7. Related Work and Discussions 

In this section, we discuss related techniques to our paper, mak- 
ing connections to a couple of notable bidirectional program- 
ming approaches, namely semantic bidirectionalization and the van 
Laarhoven representation of lenses. 

7.1 Semantic Bidirectionalization 

An alternative way of building bidirectional transformations other 
than lenses is to mechanically transform existing unidirectional 
programs to obtain a backward counterpart, a technique known as 
bidirectionalization [20], Different flavors of bidirectionalization 
have been proposed: syntactic [20], semantic [21, 22, 33, 41], and 
a combination of the two [35, 36]. Syntactic bidirectionalization 
inspects a forward function definition written in a somehow re- 
stricted syntactic representation and synthesizes a definition for the 
backward version. Semantic bidirectionalization on the other hand 
treats a polymorphic get as a semantic object, applying the function 
independently to a collection of unique identifiers, and the free the- 
orems arising from parametricity states that whatever happens to 
those identifiers happens in the same way to any other inputs — this 
information is sufficient to construct the backward transformation. 

Our framework can be viewed as a more general form of 
semantic bidirectionalization. For example, giving a function of type 
Va. [a] — > [a], a bidirectionalization engine in the style of [33] can 
be straightforwardly implemented in our framework as follows. 

bff :: (Va. [a] — » [a]) — > (Eq a => L [a] [a]) 
bff f = unlift list (lsequence list o /) 

Replacing unlift list and lsequence list with unliftT and Isequence, 
we also obtain the datatype generic version [33]. 

With the addition of observe and the monadic unlifting functions, 
we are also able to cover extensions of semantic bidirectionaliza- 
tion [21, 22] in a simpler and more fundamental way. For example, 
lift.02 (and other n-ary observations-lifting functions) has to be a 
primitive previously [21, 22], but can now be derived from observe, 
lift and (©) in our framework. 

Our work’s unique ability of combining lenses and semantic 
bidirectionalization results in more applicability and control than 
those offered by bidirectionalization alone: user-defined lenses on 
base types can now be passed to higher-order functions. For example, 
Q5 of Use Case “STRING” in XML Query Use Case ( http : //www . 
w3.org/TR/xquery-use-cases) which involves concatenation 
of strings in the transformation, can be handled by our technique, 
but not previously with bidirectionalization [21, 22, 33, 41], We 
believe that with the proposal in this paper, all queries in XML 
Query Use Case can now be bidirectionalized. In a sense we are 
a step forward to the best of both worlds: gaining convenience in 
programming without losing expressiveness. 
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The handling of observation in this paper follows the idea of our 
previous work [21, 22] to record only the observations that actually 
happened, not those that may. The latter approach used in [33, 41] 
has the advantage of not requiring a monad, but at the same time 
not applicable to monomorphic transformations, as the set of the 
possible observation results is generally infinite. 

7.2 Functional Representation of Bidirectional 
Transformations 

There exists another functional representation of lenses known as the 
van Laarhoven representation [26, 32]. This representation, adopted 
by the Haskell library lens, encodes bidirectional transformations 
of type LAB as functions of the following type. 

V/. Functor f => (B -> / B) -> (A -> / A) 

Intuitively, we can read A — > f A as updates on A and a lens 
in this representation maps updates on B (view) to updates on A 
(source), resulting in a “put-back based” style of programming [27]. 
The van Laarhoven representation also has its root in the Yoneda 
Lemma [17, 24]; unlike ours which applies the Yoneda Lemma to 
L (— ) V, they apply the Yoneda Lemma to a functor ( V, V — > 
{—))■ Note that the lens type L S V is isomorphic to the type 
S -¥ (V,V -¥ S). 

Compared to our approach, the van Laarhoven representation 
is rather inconvenient for applicative-style programming. It cannot 
be used to derive a put when a get is already given, as in bidirec- 
tionalization [20-22, 33, 35, 36, 41] and the classical view update 
problem [1, 6, 8, 13], especially in a higher-order setting. In the van 
Laarhoven representation, a bidirectional transformation t :: L A B, 
which has get £ :: A — > B, is represented as a function from some 
B structure to some A structure. This difference in direction poses 
a significant challenge for higher-order programs, because struc- 
tures of abstractions and applications are not preserved by inverting 
the direction of — K In contrast, our construction of put from get 
is straightforward; replacing base type operations with the lifted 
bidirectional versions is suffice as shown in the unlinesi, and evalc 
examples (monadification is only needed when supporting observa- 
tions). Moreover, the van Laarhoven representation does not extend 
well to data structures: n-ary functions in the representation do not 
correspond to n-ary lenses. As a result, the van Laarhoven repre- 
sentation itself is not useful to write bidirectional programs such as 
unlinesi and evah, . Actually as far as we are aware, higher-order 
programming with the van Laarhoven representation has not been 
investigated before. 

By using the Yoneda embedding, we can also express LAB as 
functions of type Vv. L B v — > L A t;. It is worth mentioning 
that L (— ) V also forms a lax monoidal functor under some 
conditions [30]; for example, V must be a monoid. However, 
although their requirement fits well for their purpose of constructing 
HTML pages with forms, we cannot assume such a suitable monoid 
structure for a general V . Moreover, similarly to the van Laarhoven 
representation, this representation cannot be used to derive a put 
from a get. 

8. Conclusion 

We have proposed a novel framework of applicative bidirectional 
programming, which features the strengths of lens [4, 9, 10] and 
semantics bidirectionalization [21, 22, 33, 41], In our framework, 
one can construct bidirectional transformations in an applicative 
style, almost in the same way as in a usual functional language. 
The well-behavedness of the resulting bidirectional transformations 
are guaranteed by construction. As a result, complex bidirectional 
programs can be now designed and implemented with reasonable 
efforts. 



A future step will be to extend the current ability of handling 
shape updates. It is important to relax the restriction that only closed 
expressions can be unlifted to enable more practical programming. 
A possible solution to this problem would be to abstract certain 
kind of containers in addition to base-type values, which is likely to 
lead to a more fine-grained treatment of lens combinators and shape 
updates. 
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